IBIS Macromodel Task Group Meeting date: 08 December 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai * Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Todd Bermensolo Rui Yang Luminous Computing David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the agenda email mistakenly said this is the last meeting of the year. Next week's meeting on December 15th will be the last of the year, and meetings normally scheduled for December 22nd and December 29th are cancelled. - Walter said that at some point he would like to discuss the clock-forwarding BIRD (BIRD204) and some combinations we may or may not want to support. For example, if the DQ model says it takes "times" as a clock input, then the associated DQS model should return clock ticks in its clock_times argument. ------------- Review of ARs: - Randy to send his GDDR6x simulation results presentation to the ATM list. - Done. Arpad noted that Steve Parker had posted it to the ATM work archive. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the December 1st meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: Redriver Flow Issues: Alaeddin reviewed his new presentation "Symmetric Processing of IBIS AMI Redrivers and Handling AMI_Init only Models_ATM". He noted that he had taken an AR at a previous meeting to document his flow ideas with figures in addition to his mathematical notation. slides 5-7: Simple Tx->Rx flow - In the current flow, the Tx Init gets the unequalized post-channel IR. - What's nice about this legacy approach is that Tx and Rx Init functions get invoked one time each and in sequence. slides 8-11: Redriver Flow - Note that pre-channel and post-channel terminology is with respect to the redriver (also known as upstream and downstream channels). - The IR of the channel after any Tx is always passed to the Tx unequalized. - Note that convolution is used so the final Rx sees the entire upstream information (slide 11). Walter noted that slide 11 does not depict the flow currently in the specification. In the current flow, the output of the Redriver Rx is convolved with the output of the final Rx, and the redriver Tx and the final Rx only see the downstream channel information. This is the flaw in the current redriver flow, the redriver Tx and final Rx don't receive the upstream IR information. slide 12 - handling Init-Only models Alaeddin thought it was not a good idea to exclude existing model types from the flow. The slide proposes that effects from Init-Only models can be handled in a GetWave flow by substituting the IR returned by Init in place of its nearest connected channel's original IR. He noted that he considers "combined" Tx/Rx redriver models a pathological case, and they break the "nearest channel" rule because a combined Tx/Rx connects to both the upstream and downstream channels. He said in his experience these combined Tx/Rx models are disappearing in the industry, and he hopes this continues. Walter said that Init-Only models can be handled as long as they are the upstream models, i.e., the first models encountered in the left to right progression. As soon as you have a GetWave-Only model upstream of an Init-Only model, the Init-Only model is not getting the full IR information it needs. Curtis said a Dual model upstream of an Init-Only model could cause double counting of the Dual model's effects in time domain flow or could require deconvolution. slide 14 - Proposed new Keywords (Note: actually AMI Reserved Parameters) Alaeddin proposed two new keywords for the redriver Tx and Rx respectively. AMI_RE_TX_EQ_MODE = POST (or PRE, or BOTH) AMI_RE_RX_EQ_MODE = PRE (or POST, or BOTH) The default for the Tx is POST, and the default for the Rx is PRE, to match the existing specification. However, either could be set to PRE, POST, or BOTH depending on what the model maker wants for input IRs to Init. slides 15-16: Example flows with new parameter settings. slide 15 - Note that if the AMI_RE_TX_EQ_MODE is PRE, the EDA tool knows it has to explicitly convolve the output of the redriver Tx with the downstream channel before passing it to the final Rx. Arpad asked for clarification of the meaning of the left-pointing white arrows starting in slide 5. He asked if these were meant to convey the fact that the original IR of the channel (measured at the receiver) is what is passed into the Tx in the existing flow. Alaeddin agreed with Arpad's explanation. Walter noted that his recent proposal had been to change the flow so that the input to any Tx is its upstream IR (unlike the current flow, in which the input to a Tx is its downstream channel's IR). He said in the case of the initial Tx, the input would be a unit IR. The EDA tool would then handle convolving the output of the Tx Init with the downstream channel IR. He wants the Tx to only look at the upstream information, just as the Rx only looks at the upstream information. He said this would make the Init flow symmetric with the GetWave flow and would simplify things considerably. He asked Alaeddin what he thought of this proposal. Alaeddin said the Tx Init functions might be expecting something reasonably smooth and could have trouble with an ideal unit IR. Walter noted that if a channel was very short the Tx would have to deal with such a case anyway. Alaeddin said that since these are behavioral models anyway, he could see the model maker wanting the flexibility to give PRE, POST, or BOTH as inputs. This extra flexibility might allow the model maker to minimize the equalization adaptation that has to take place during time domain simulation (i.e., reduce the Ignore_Bits value). However, he agreed Walter's proposal could work. Walter said the whole point of the original flow passing the downstream IR to the Tx was to try to be clever and give the Tx information so it could adapt. However, in hindsight, we've seen this wasn't a great approach. In practice, with this method the Tx models often over equalize relative to what they would do with proper back-channel communication with the Rx. Alaeddin said that back-channel gets complicated, and if it becomes widely adopted in the industry maybe it will become a real option. Walter said that when the statistical BCI BIRD is part of the standard, industry adoption may improve. Arpad asked if the approach in Alaeddin's slides would still leave us with problems mixing GetWave-Only, Init-Only, and Dual models. He recalled that Ambrish had said last week that the specification did not originally envision a GetWave function that depended on the IR input to Init. Arpad asked, if that's the only issue, could we resolve it with a parameter that says GetWave depends on the Init results? Alaeddin said there are already many redriver models with an Init-Only Rx and a Get-Wave only Tx that exist in the industry. We have to make sure not to disallow this combination. He said handling upstream Init-Only models isn't hard, and the effects of such models can be folded into the IR of the channel to which they're connected. Hansel asked if Alaeddin's proposal was making the assumption that the Tx has identical rising and falling edges, since it proposed folding the output of the Init-Only model into the channel IR. Alaeddin said the case of differing rising and falling edge rates is inherently non-linear, and Init can't handle that. Wei-hsing agreed with Alaeddin that Init-Only models are limited to LTI, and the model maker needs to provide a GetWave to deal with rising/falling edge rate differences. Walter said that if you have asymmetric rising/falling edges, and you think the effect is important, and you don't have a GetWave, then there are creative things an EDA tool could do to make a proxy GetWave that reflects the rise/fall asymmetry by looking at the rising and falling IRs separately. Wei-hsing agreed and noted a paper he had given at the DesignCon Summit two years ago. He said there are certain shortcomings on the modeling side that can be covered over by the EDA tool. If we make the language in the specification too restrictive, we might deprive the tool of a chance to compensate and deal with problematic cases. Walter said we have a simple flow that is valid and reliable if everything upstream of the terminal Rx is Init-Only, and the terminal Rx is GetWave-Only (or Dual). That works fine. This can be generalized a bit to say that if we have a chain of Tx and Rx models, then everything upstream of the first model with a GetWave can be Init-Only, everything including and after the first model with a GetWave should be Dual, up until the terminal Rx, which may be Dual or GetWave-Only. In that situation we have a straightforward flow and the tool should be able to simulate reliably. Arpad asked if we could just put language to that effect into the specification and be done with this issue. Alaeddin said he didn't understand why we would want to restrict Init-Only models. Walter said that if an Init-Only model comes after a model with GetWave, the tool needs to use deconvolution, which can be problematic. Alaeddin agreed that deconvolution is problematic, but he said he thought GetWave-Only models were more troublesome than Init-Only, and we should certainly never expect the tool to synthesize an effective IR from a GetWave- Only model. Walter said he had asserted that any Init-Only model can/should be made into a Dual model by the model maker. This left only GetWave-Only models to address. Walter said that any time there's a GetWave-Only model in the chain, any downstream Init-Only model is rendered useless even in the statistical flow, and any models downstream can't rely on their Init functions providing proper equalization information to their GetWave functions. He said it would be nice if we introduced some parameters to indicate various dependencies so tool vendors don't have to qualify models to make sure they run effectively under various conditions. Arpad said we will continue this discussion next week, and he asked everyone to focus on what we can do in the specification to address these issues. Alaeddin suggested that it would be helpful if other proposals were put into the form used in his presentation. He thought this would make comparisons easier for everyone. AR: Arpad to ask Steve Parker to post Alaeddin's presentation to the ATM archives. ------------- Next meeting: 15 December 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives